Engagement scope guard: every network target read and checked (DNS, scanners, nc) - #18

Phase 10, step 5 plan, PR 4 (decision D14i).  Until now no code read a
network step's target: the engagement's scope was only recorded.
codebud_sec/scope.py reads every target a network tool will contact
from its command line and checks it against the engagement:

  - active tools (nmap, masscan, nc, ncat) are refused when a target is
    outside the scope, excluded, or the window is closed -- a hard
    block: a model's plan is untrusted, and the UK AISI incident report
    (4 Aug 2026) shows prompt-level scope is not enough;
  - passive lookups (dig, host) out of scope ask for confirmation,
    D14's warn-and-confirm kept for them.

A target that cannot be read is refused.  Each tool's parser knows which
options take values; an unknown option is refused, since its value
could be a target the guard cannot see.  Hosts a tool contacts besides
its target are targets too: DNS servers (dig @, nmap --dns-servers),
proxies (nc -x, ncat --proxy, nmap --proxies), the idle-scan zombie
(nmap -sI) and the FTP relay (nmap -b).  nmap -iR (random hosts),
--resume, masscan -c and dig -f are refused; target lists (-iL) are
read only from a file inside the project.  Ranges -- CIDRs, masscan
a-b, nmap octet ranges by their bounding range -- must fit in the scope
as a whole, and engagement.covers_network() checks that against the
excluded networks too.  A name never matches addresses: resolving it
would itself be a network action.

A step that declares the network with a tool the guard cannot read is
refused, and an engagement at privacy trusted (no isolation) refuses
every command.  ScopeGuard.activate() registers the guard with the
core's step-check hook; the codebud-sec entry point will open the
engagement and activate it (PR 7).  CORE_API widens by codebud.safety
(the hook) and codebud.privacy, deliberately.

HTTP tools, web fuzzers and TLS scanners follow in PR 4b.  Architecture
layout, build list and test list updated.

Review of PR #18, finding 3.  nmap's scripts can contact hosts the
command line never names, and the guard let them through:

  - broadcast-* scripts send to the whole local network; they are in
    the broadcast and discovery categories and partly in safe, so
    --script safe or --script discovery runs them too;
  - targets-* scripts with --script-args newtargets add the hosts they
    find as scan targets;
  - external scripts send data to third-party services (whois, ASN).

--script is refused when any name, category or glob in it could select
these -- broadcast, discovery, safe, external, all, broadcast*,
targets-*, or a glob matching them -- in a list or a boolean expression
(it errs strict: "not broadcast" is refused too, since expressions are
not evaluated); --script-args with newtargets is refused.  -sC and
named scripts such as http-title stay allowed.  Eleven cases, all
allowed before.

Re-review of PR #18.  The guard judged only command steps, but
web_search is a network step too: it sends the query to DuckDuckGo, a
third party outside any engagement.  Web search is off by default and
the security profiles keep it off, but the guard should not depend on a
setting; it now refuses web_search steps.  File tools and host_network
stay on this machine and are untouched (tested).